home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000013_owner-urn-ietf _Mon Mar 10 10:30:27 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id KAA21569
  3.     for urn-ietf-out; Mon, 10 Mar 1997 10:30:27 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA21564
  6.     for <urn-ietf@services.bunyip.com>; Mon, 10 Mar 1997 10:30:24 -0500 (EST)
  7. Received: from relay.hq.tis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA05703  (mail destined for urn-ietf@services.bunyip.com); Mon, 10 Mar 97 10:30:18 -0500
  9. Received: by relay.hq.tis.com; id KAA29814; Mon, 10 Mar 1997 10:28:25 -0500 (EST)
  10. Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (3.2)
  11.     id xma029779; Mon, 10 Mar 97 10:28:03 -0500
  12. Received: from [10.33.112.20] (flapdoodle.hq.tis.com [10.33.112.20]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id KAA24362 for <urn-ietf@bunyip.com>; Mon, 10 Mar 1997 10:26:16 -0500 (EST)
  13. X-Sender: lewis@pop.hq.tis.com
  14. Message-Id: <v03007801af49ca4a675d@[10.33.112.20]>
  15. In-Reply-To: <v03010d00af465bab9f56@DialupEudora>
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset="iso-8859-1"
  18. Date: Mon, 10 Mar 1997 10:15:45 -0500
  19. To: urn-ietf@bunyip.com
  20. From: Edward Lewis <lewis@tis.com>
  21. Subject: Re: [URN] NAPTR doc (draft-ietf-urn-naptr-03.txt)
  22. Content-Transfer-Encoding: 8bit
  23. X-MIME-Autoconverted: from quoted-printable to 8bit by services.bunyip.com id KAA21565
  24. Sender: owner-urn-ietf@Bunyip.Com
  25. Precedence: bulk
  26. Reply-To: Edward Lewis <lewis@tis.com>
  27. Errors-To: owner-urn-ietf@Bunyip.Com
  28.  
  29. At 7:31 PM -0500 3/7/97, Karen R. Sollins wrote:
  30. >Third, I am still unhappy the treatment of security, both for myself and
  31. ...
  32. >DNSSEC will address them has been studied.  I do not think that NAPTR needs
  33. >to be extremely ruggedized with respect to security, but I do think that as
  34.  
  35. I've been involved in DNSSEC, so when I see it mentioned in a thread, I
  36. wake up and read the document for DNS-type things.
  37.  
  38. First minor things - on line 598 "DNS_CHAR" is defined.  It is never used,
  39. so I don't know for certain what it is supposed to mean (so maybe it should
  40. be deleted).  If it is the legal, non-escaped chars in DNS, then underscore
  41. ("_") should not be there, instead a hypen ("-") should be included as well
  42. as upper case characters.
  43.  
  44. In the paragrapgh following, "...URI shall be a legal domain name" should
  45. be either:
  46.  
  47. "...URI MUST be a legal domain name"
  48.  
  49. or better yet:
  50.  
  51. "...URI MUST be a legal domain name and SHOULD BE a legal host name"
  52.  
  53. or perhaps:
  54.  
  55. "...URI MUST be a legal domain name and MUST BE a legal host name"
  56.                                         ^^^^
  57.  
  58. There is some confusion over legal domain names and host names, and the
  59. reference to 1123 does not make things clearer.  draft-ietf-dnsind-
  60. clarify-0?.txt is the latest best way to define the binary form of domain
  61. names.  All of the drafts I have seen on defining the ascii/zone-file form
  62. of a domain name have expired.  I haven't followed legal host names as
  63. closely, but I think RFC 1123 is probably the best reference for that.
  64.  
  65. The distinction is this: a domain name can have non-printable bytes in it
  66. which is legal.  In the zone file, the non-printable bytes must conform to
  67. a specific escape syntax ("\<char>" or "\<three-digits>").  A legal domain
  68. name might not be a legal host name.  (There are length limits for domain
  69. names.)
  70.  
  71. About the security (the reason I clipped the above mail message),
  72. specifically related to DNSSEC:
  73.  
  74. DNSSEC will (in a nutshell) let you trust that the NAPTR record received is
  75. what the owner submitted, i.e., no one has substituted a fake record.  (Of
  76. course, DNSSEC will not prevent either bad or malicious data from being
  77. entered, it will just make the insertion of
  78. malicious-data-that-successfully-causes-bad-things harder.)  DNSSEC will
  79. also provide a mechanism for retrieving public keys - if you need that sort
  80. of thing.
  81.  
  82. DNSSEC does not address denial of service attacks against name servers.
  83.  
  84. I'm not saying "trust me, DNSSEC will take care of all DNS security issues"
  85. but you probably shouldn't dwell on them too much in the NAPTR document.
  86. (As it is now, IMHO document is fine on security.)  I don't see a security
  87. concern in the document, perhaps you do want to consider security within
  88. the resolver.  I admit to have not read other URN documents...but I'd
  89. venture to say you may want to include a digital signature to authenticate
  90. a URN processed response.  (DNSSEC only helps get you to the URN resolver,
  91. we don't help the URN resolver's security.)  But such a topic is outside
  92. the scope of the NAPTR document.
  93.  
  94. PS -
  95.  
  96. One question - has IANA approved the number 35 for NAPTR?  It's not on
  97. their web page (ftp://ftp.isi.edu/in-notes/iana/assignments/dns-parameters)
  98. yet.  (The page is rather old - dated January 14.)
  99.  
  100. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  101. Edward Lewis                      Trusted Information Systems
  102. Phone: 301-854-5794               Email: lewis@tis.com
  103.  
  104.